Active ticket with dynamic characteristic such as appearance with various validation options

ABSTRACT

A method and apparatus is provided for providing an active ticket in a mobile terminal for use by a mobile terminal user, wherein at least one active ticket has a ticket characteristic that dynamically changes based on one or more states in a life cycle of the active ticket. Dynamic changes to the ticket characteristic include multimedia changes or other presentation data, including text, sound (audio), animation, video, still pictures, or some combination thereof. The active ticket can have different states in it&#39;s life cycle, such as purchased, validated, invalid for certain events. Also the ticket service provider or issuer can send new control data to change the characteristic and/or contents of the active ticket.

BACKGROUND OF THE INVENTION

1. Field Of Invention

This invention relates to a ticketing system; and more particularly, toa digital ticketing system for use in conjunction with a mobile phone orterminal.

2. Description of Related Art

There are many different known ways to provide a ticket to allow someoneto gain access to an event or location. One known way is to distribute aphysical ticket having the time and place of the event printed thereon.The ticket is typically handed to a gate attendant when someone entersthe premise at which the event is being held. However, the knownphysical tickets have several problems associated with them,including: 1) They cannot be delivered digitally. In other words, it isimpossible to deliver tickets remotely. 2) It is hard to check whetherthe known ticket is a stolen ticket in most cases, e.g. movie ticket. 3)It is hard to do digital management for the tickets. 4) The physicalticket wastes a lot of paper.

More recently, digital tickets have been developed and are now beingused, including the use of the same in mobile phones or terminals. Adigital ticket is a certificate that guarantees certain rights for theticket owner. There are many applications for digital tickets, whichinclude, e.g., an electronic stamp, an electronic coupon or a voucher.But most digital tickets are merely digital textual tickets in whichrights of the ticket owner are described by text.

At the same time the digital ticket is becoming popular, some issues arealso introduced. Digital tickets are quite suitable for delivering overnetworks, which makes it easy to be altered, pirated or superdistributedwithout any change and control. The digital copy of the ticket can bethe same as the original that makes the ticket verification atredemption more difficult. Many solutions have been proposed forprotecting digital tickets, but the extra protection often makes thedigital ticket system too complicated, and therefore causes usabilityissues which impedes the digital ticket uses.

For example, in a mobile environment the digital ticket has some knownproblems. Mainly these are related to security issues. It is very easyto send some digital information from terminal to terminal and hencewithout proper security measures superdistribution of tickets ispossible. Various techniques have been developed to overcome thisproblem. Many ticket validation systems are quite complicated anddiminish the usability of such digital ticket systems.

Overall, mobile ticketing is a problem because of the copy protectionissue. There are two basic known approaches in use today:

1. Mobile ticketing is now used in proprietary formats and used onlywith ticketing schemes with low value and low risk (e.g., SMS text basedticketing) or bar codes. This solution has a copy protection problem inthat there is no protection: only the first one who is presenting theticket gets the goods/access. This requires a cross check at thevalidation. Another option is that some kind of identification of theuser is required in addition (e.g., phone number, drivers license). Theproblem is that the ticket validation should be a very fast process andthis slows the process down.

2. Another alternative is to use security mechanisms for ticketvalidation and storage. Traditional cryptographic approaches, such asencryption/decryption, digital signature, etc., are used for protectingdigital textual ticket, but it is heavy and costly for mobiledevices/services as they should use the same scheme and has usabilityproblem at the ticket redemption point because the following reasons:

-   -   a) Verification is needed when receiving the ticket.    -   b) Cross verification is needed during the redemption between        the ticket owner device and the redemption point device.        Both of them cause extra communication and process cost. Key        management is known to be a difficult task. System establishment        is also very expensive. A trade-off has to be made between high        security and easy usability.

In addition, the known digital tickets have several other problems,including: 1) It is easy to make an illegal copy of the known digitalticket that is impossible to validate without the help of a machine. 2)Copy protection for digital tickets is typically hard to implement,because, for example, cryptography and key handling for cryptography iscomplex and potentially risky or costly because it needs hardware secureelements on the terminal, etc. 3) Usability of the known digital ticketsis a problem due to the complicated protection based on cryptography. 4)The known digital ticket is hard to conduct redemption/validity check,i.e. it is impossible to check/inspect by a human without machines. 5)The digital ticket makes it hard to support additional business forextra revenue. 6) The life cycle of the known digital ticket is short,and the content of the ticket is hard to renew or update after issuing(the current solution is issuing a new ticket; however, the usertypically needs to delete the old ticket.)

The present invention provides a solution to the aforementioned problemsin the art.

SUMMARY OF INVENTION

In its broadest sense, the present invention provides a new and uniquemethod and apparatus for providing an active ticket in a mobile terminalfor use by a mobile terminal user, wherein at least one active tickethas a ticket characteristic that dynamically changes based on one ormore states in a life cycle of the active ticket. Dynamic changes to theticket characteristic include either multimedia changes or otherpresentation data, including text, sound, animation, video, stillpictures; or a movement of the mobile terminal, an emission of lighttherefrom, a change of shape; or some combination thereof.

The active ticket can have different states in it's life cycle, such aspurchased, template, pre-valid, validated, invalid for certain events.Also the ticket service provider or issuer can send new control data tochange the characteristic and/or contents of the active ticket. Thisinformation is sent only to the mobile terminal of the originalpurchaser of the active ticket, so unauthorized (i.e. pirated)superdistributed tickets, if any, will not receive this updatedinformation. Moreover, it is also possible to change the characteristicor appearance of the ticket according to this information.

The ticket is active such that it contains an algorithm or program tochange its multimedia or other presentation data according to differentsituations. The active ticket can contain text, sound, animation, video,or still pictures together or alone, including the algorithm forpresenting it.

The active ticket is dynamic during its lifetime and better yet, newcontrol data can be sent to it to change the algorithm, give thealgorithm new parameter values or change other presentation data. Thiscontrol data is a part of the active ticket but is received for exampleat a certain time and/or location, or just before the ticket is about tobe used. This control data is sent only to legally purchased tickets andany copy made illegally is left without it, as it is not registered atthe ticket service provider or issuer who sends the control data. Afterreceiving the control data the active ticket is easily distinguishablefrom the illegal ones. Security here is enough for tickets with low andmedium value.

The present invention allows ticket validation without machines. Forexample, with the copy protection mechanism of the active ticket,validation by the human eye is easy: the control data part can changethe appearance of the ticket to, for example, a certain music or picturewith a certain background. Ticket verification can be conducted based onimage change, sound change and/or frequency change (duration change) ofthe animation. Without the control data the ticket can sound and lookdifferent indicating that the ticket is invalid. The validation canagain change the ticket status.

According to the present invention, ticket validation can be based onunique sounds provided by the active ticket. This kind of machinery istypically inexpensive and can be processed at a server. Another optionis to use certain sounds that can be verified by a human.

Ticket validation can also be based on unique light emitted by theactive ticket. When the active ticket is started with the validationfunction, it may emit light in a sequence recognizable by the validationterminal, based on relative time duration of the luminous intensitysequences, so that the validation terminal can tell if the ticket isvalid or not. Another option is to use relative intensity of theluminance for the signalling.

In effect, the invention is an active multimedia ticket that can replacethe current existing tickets and provide more business opportunities andflexibility. The multimedia feature of the active ticket shows theticket information and other information by video, audio, animation orsome combination thereof. The active ticket is dynamic, which containsan algorithm to change its appearance when some event happens (e.g. whenexpiration time comes, when ticket has been used, etc.). In addition,new control data can also be sent to the active ticket to furthercontrol future ticket appearance.

This technique can be used for ticket renewing and sending advertisementinformation to the ticket user remotely, as well as for organizing aticket-related campaign or a ticket game.

The active multimedia ticket of the present invention also providesvarious options for ticket validation based on sound, light, animationfrequency and so on.

Some advantages of the active ticket according to the present inventionare as follows:

With the active ticket, it is easy to introduce entertainment into theticket business, therefore attracting more mobile digital ticketapplications. It is flexible to support various business models,therefore, provide more new revenue making opportunities for ticketissuers.

The active ticket is more secure, harder to make a copy of, and easierto detect than any existing ticket. Because the active ticket issoftware based, it can be sent to the ticket user's handset andautomatically installed. In effect, there is no use in copying thecurrent appearance of the ticket, because the future appearance will bedifferent from the current one. In view of this, it is hard to forge avalid ticket.

With the above advantages, the active ticket holds advanced usabilityover the prior art tickets because cross verification during theredemption between the ticket owner device and the redemption pointdevice is not essential. Just by viewing and/or listening to the activeticket, the redemption inspector can verify if the ticket is valid.

The active ticket according to the present invention is also easy toimplement since there is no need to handle cryptographic keys at theterminal side and it can be implemented by Java technology

The active ticket according to the present invention is more flexibleand can support various business models flexibly, because it is suitedfor: ticket inspection/verification by human eyes; ticket verificationdigitally by a device; one ticket container can support multipletickets, so each ticket life can be endless; introducing entertainmentinto the ticket business so the user can participate in more ticketrelated activities, such as competition, gaming, etc.

The active ticket according to the present invention is more economicalbecause the active ticket life-circle can be endless, shared bydifferent events, the ticket carrier can take multiple tickets andwasted ticket paper will disappear.

The active ticket according to the present invention is more meaningfulbecause video and audio mean much more than text, and the activemultimedia ticket can contain more or enhanced information than otherkinds of ticket.

Digital tickets are now being used in mobile terminals. Mobile terminalsallow purchasing, downloading and viewing the digital tickets at anytimeand anywhere. In view of this, the present invention brings true valuenot only to users, but also to ticket issuers. For the users, they mayview the ticket on their mobile terminals and contact the ticket issueror service provider easily. For the ticket issuers, they would beallowed to provide information to the users directly and inform themabout changes or other details also after purchase.

The active ticket can be delivered over the Internet or mobile networks.One special way for active ticket delivery can be Wireless AccessProtocol (WAP) push Java mobile information device profile (MIDP)carried ticket to mobile handsets. The ticket is carried by a Javaapplication, such as MIDlet, therefore can be installed and played atJava-enabled mobile handsets, but cannot be super-forwarded afterinstallation. However, it is important to note that the scope of theinvention is not intended to be limited to only JAVA based programmingenvironments; instead, the scope of the invention is intended to includeimplementations other than using JAVA based programming environments.

The less secure simple ticketing technique according to the presentinvention would fit for tickets where the issuer does not want to have apre-established relationship and security application on the mobileterminal. The implementation does not require a very ticket specificimplementation on the mobile terminal and is therefore easilyimplemented, since no device hardware or platform, per se, is necessary.

From a business point of view, system establishment is a key point. Inorder to introduce a new service that can replace an existing system, itis very important to provide the potential for new revenueopportunities. The introduction of the new system is more likelypossible when established based on the existing infrastructure.Therefore, it is easy to be deployed by service providers. The usesenvisioned for the present invention include, but are intended to belimited to:

-   -   Entrance (movie, opera, sport game, museum) ticket,    -   Complex multimedia ticket with event campaign involved,    -   Travel ticket (bus ticket, periodic ticket, time ticket, air        ticket),    -   Club (swimming, tennis, etc. member ticket) ticket,    -   Group ticket (school ticket), and    -   Campaign ticket (e.g. coupon ticket—with special offer described        by text, image and audio, etc.).        One active ticket application can work as a ticket folder to        support all of above tickets in parallel or in series.        Alternatively, the tickets can be in different active ticket        applications (e.g., application suites in Java implementations).

In addition to the aforementioned method, the present invention alsoprovides a new and unique mobile terminal for providing an active ticketfor use by a mobile terminal user, wherein the mobile terminal includesa mobile active ticket application module that provides at least oneactive ticket having a ticket characteristic that dynamically changesbased on one or more states in a life cycle of the active ticket thathas capability to access other terminal components (e.g. mWallet) bybeing verified as trusted by the terminal, as well as a new ticketservice provider for communicating with a mobile terminal, wherein theticket service provider includes a ticket issuer module that provides toa mobile terminal either at least one active ticket or controlinformation for activating or deactivating at least one active ticketfor use by a mobile terminal user, the at least one active ticket havinga ticket characteristic that dynamically changes based on one or morestates in a life cycle of the active ticket. The invention also providesa new wireless network consistent with the aforementioned.

Java Implementation

Considering Java enabled mobile terminals, additions needed for activeticketing would be small: Support for a new ticket type—or another wayto communicate to the terminal that this is a ticket. This will providethat the ticket is automatically installed in the ticket folder. Suchsupport may be added to the Mobile Wallet.

The active ticket could be an MIDP, Personal Java, or C-applicationdownloaded to the device. Optionally, there could be a ticket folder inthe terminal that can handle the ticket. It can forward partialinformation carried by the ticket, such as an advertisement, purchasesettings, etc. (This information should be allowed to be forwarded bythe ticket service provider or issuer.)

Control data can be pushed to the applications, or it can be fetchedwhen the application is communicating with the server side usingexisting communication technology.

The ticket issuer can control the dynamic characteristic or appearancechange remotely by providing a control token to the mobile terminal. Thetoken sending may be uniquely based on the International MobileEquipment Identification (IMEI) code, or other terminal or subscriberidentification, even an IP address. So the sending of the informationcan only reach the registered ticket user's personal trusted device.Timing may be based on the issuer's clock, so it would be hard to attackthe timer. This model is suitable for cases when the ticket value ishigh, human eyes conduct the ticket redemption check or validitionchecking digitally, or online digital ticket verification. This way isalso convenient for the issuer to broadcast (multicast) extra multimediato the ticket holders, therefore it is easy to set up ticketing relatedentertainment and campaign.

Ticket validation by the human can be based on the presentation of thedata that is only available when the control data has been received.This makes copying much more diffcult beforehand but still thevalidation without machine is easy.

Validation based on audio can be implemented for example with relativefrequency change. In addition, an audio watermark (time-stamp, location,event) can also be embedded into the ticket using a secret key.Machine-based verifier can use the same secret key to detect and verifythe authority of the ticket by listening to the sound of the ticket.

BRIEF DESCRIPTION OF THE DRAWING

The drawing, not drawn to scale, includes the following Figures:

FIG. 1 shows a block diagram of an active ticket system architectureaccording to the present invention.

FIG. 2 shows a block diagram of a known mobile transaction (MeT)multimedia ticket data format that may be used to implement the presentinvention.

FIG. 3 shows ticket samples, and includes FIG. 3A that shows a buy movieticket, FIG. 3B that shows a valid movie ticket and FIG. 3C that showsan invalid movie ticket.

FIG. 4 is an illustation of a dynamic appearance of an active ticket.

FIG. 5 is an illustation of a ticket appearance in an active ticketstack.

FIG. 6 shows a diagram of an active ticketing protocol.

FIG. 7 is a diagram of valid active ticket driven methods (w/ threealternative upgrading methods).

FIG. 8 a is a diagram of prevalid active ticketing protocol.

FIG. 8 b is a diagram of an active ticketing protocol with a crosscheck.

FIG. 8 c is a diagram of a location-based active ticketing protocol.

FIG. 9 a is a diagram of a use case ticket purchase protocol.

FIG. 9 b is a diagram of an alternative use case ticket purchaseprotocol.

FIG. 10 a is a block diagram of a validation of a ticket purchase.

FIG. 10 b is a block diagram of an alternative of validation of a ticketpurchase.

DETAILED DESCRIPTION OF INVENTION FIG. 1: Active Ticket SystemArchitecture

FIG. 1 shows an active ticket system architecture generally indicated as20 having a mobile terminal 22 and a ticket service provider 24.

The mobile terminal 22 includes a ticket transaction module 22 a and amobile active ticket application module 22 b. The ticket transactionmodule 22 a provides the functionality for supporting the purchasing ofan active ticket, which can be implemented as an m-wallet in the mobilephone or micro-payment function based on short messaging service (SMS),operator billing, payment card purchase, or any current or futurepayment systems depending on the business model. The mobile activeticket application module 22 b contains a mobile active ticketapplication 22 b′ that is the ticket installed and run at the mobileterminal 22. The mobile active ticket application 22 b′ provides atleast one active ticket having a ticket characteristic that dynamicallychanges based on one or more states in a life cycle of the activeticket. The mobile active ticket application module 22 b and mobileactive ticket application 22 b′ are responsible for contacting with theticket provider 24 (issuer and inspector) and connecting with the tickettransaction module 22 a for ticket transaction (e.g. payment). By way ofexample, the mobile active ticket application module 22 b is shown anddescribed as including the mobile active ticket application 22 b′,although the scope of the invention is intended to includeimplementations in which the mobile active ticket application 22 b′ isformed as a separate unit, or in which the mobile active ticketapplication module 22 b and the mobile active ticket application 22 b′are formed as part of the same unit. The mobile terminal may alsoincludes a centralized ticket manager (not shown) for viewing and/ormanaging the tickets that a user has, thus saving the user the effort ofstaring each active ticket application when wanting to view a list oftickets in different active ticket applications. The centralized ticketmanager may also form part of the mobile active ticket applicationmodule 22 b.

The ticket service provider 24 includes a ticket generator module 24 a,a ticket issuer 24 b, a ticket inspector 24 c and a ticket data and userinformation logs 24 d. The ticket generator module 24 a is responsiblefor generating tickets for the mobile terminal users. The ticket issuer24 b provides to the mobile terminal 22 either at least one activeticket or control information for activating or deactivating the atleast one active ticket for use by a mobile terminal user, and isresponsible for both delivery and updating of the active ticket. Theticket inspector 24 c is the function or person to check the validity ofthe active ticket.

The mobile terminal 22, the ticket service provider 24 andaforementioned modules and elements thereof, including the tickettransaction module 22 a, mobile active ticket module 22 b, ticketgenerator module 24 a and ticket issuer 24 b, may be implemented usinghardware, software, or a combination thereof. The scope of the inventionis not intended to be limited to any particular implementation thereof.For example, a typical software implementation may include using amicroprocessor architecture having a microprocessor, a random accessmemory (RAM), a read only memory (ROM), an input/out devices and acontrol, address and databus for connecting the same.

FIG. 2: MeT Multimedia Ticket Data Format

FIG. 2 shows the MeT Multimedia ticket format generally indicated as 30,which in one embodiment is adapted to support the active ticketingformat that is the subject matter of this patent application. The MeTMultimedia ticket format 30 includes an MMS header 32 and a message body34, which has presentation 34 a, image/jpeg 34 b, text/plain 34 c andaudio/wav 34 d fields.

For example, for a valid ticket appearance the active ticket follows theMeT Multimedia ticket format as shown. Therefore, it is possible for anMeT compatible ticket player and inspector to recognize the ticket.

For a pre-valid ticket appearance and used ticket appearance, there isno such ticket format support, so it is easy to identify a real ticket.

Alternatively, in another embodiment, for the pre-valid ticket, the MeTMultimedia ticket format is adapted to only carry the template of theticket format. While for the valid ticket, the valid ticket informationis filled in the MeT Multimedia ticket format. For the used ticket, thevalid ticket information is removed by the active ticket applicationmodule 22 b′ accordingly.

FIG. 3: Ticket Samples

FIG. 3 shows three different ticket samples according to the subjectmatter of the present invention, which are shown by way of example. Thescope of the invention is not intended to be limited to any partivulartext or graphic display provided on the active ticket.

FIG. 3A: Buy Movie Ticket

FIG. 3A shows an example of a buy movie ticket generally indicated as40, which is displayed on the mobile terminal 22 that enables the userto buy a movie ticket from the ticket service provider 24. The buy movieticket functionally includes a first text section 40 a indicating theaction “Buy Movie Ticket”, an image section 40 b showing a scene from amovie, a second text section 40 c indicating a whole or partial title ofthe movie, i.e. “007 Coming”, as well as a time, i.e. “16:30-18:40”, anda date, i.e. “30.1.2003”, when the movie is showing, and a third sectiongenerally indicated as 40 d having icons “Active/pay” or “Exit” for theuser to click on to pay for the movie ticket or exit the display.

FIG. 3B: Valid Movie Ticket

FIG. 3B shows an example of a valid movie ticket generally indicated as42, which is displayed on the mobile terminal 22 after the user pays forthe movie ticket. The valid movie ticket includes a first text section42 a indicating the text “Valid Movie Ticket”, an image section 40 bshowing a scene from a movie, a movie ticket confirmation no., i.e.“3467890”, the number of tickets, i.e. “(2)”, a whole or partial titleof the movie, i.e. “007”, as well as a time, i.e. “16:30-18:40”, and adate, i.e. “30.1.2003”, when the movie is showing, and a second sectiongenerally indicated as 40 c having the icons “Use” or “Exit” for theuser to click on to use the movie ticket or exit the display.

FIG. 3C: Invalid Movie Ticket

FIG. 3C shows an example of an invalid movie ticket generally indicatedas 44, which is displayed on the mobile terminal 22 that shows the userthat the movie ticket purchased from the ticket service provider 24after it is used. The invalid movie ticket includes a first text section44 a indicating the text “Invalid Movie Ticket”, an image section 44 bshowing a scene from a movie, a second text section 44 c indicating thetext “For more movie, press menu”, and a third section generallyindicated as 44 d having icons “Active/pay” or “Exit” for the user toclick on to display the menu of movies to purchase itckets for or toexit the display.

The scope of the invention is not intended to be limited to anyparticular state in the life cycle of the ticket, and is intended toinclude other states such as template, pre-valid and prepared dependingon the ticket issuer.

FIG. 4: Illustation of Dynamic Appearance of an Active Ticket

FIG. 4 shows a graph of time versus ticket appearance for a given mobileterminal, and indicates that the ticket appearance or characteristic ofan active ticket according to the present invention changes according toboth time and the status of the active ticket.

For example, during a pre-valid period of event 1, the ticket appearanceis indicated as appearance 1. When the ticket user wants to redeem theticket or it is time or at the location to redeem the ticket, the issuersends ticket data to the user's personal trusted handset, whichactivates the ticket to appearance 2, as shown. After using the ticket,a redemption point or ticket issuer drags the active ticket toappearance 3. Then the ticket comes to the next ticket event, and soforth.

The active ticket is dynamically shown. The ticket activation iscontrolled by control data issued by the ticket service provider orissuer 24 (FIG. 1). The control data indicates which kind of appearanceshould be shown. After getting the data, the mobile active ticketapplication module 22 b will function to display the ticket on themobile terminal 22 based on the instruction of the control data.

Alternatively, the scope of the invention is also intended to includespecial cases or implementations where high security is desired, andthere is hardware available, the control data may be sent from a secureelement inside, or attached, or communicating with the mobile terminal.In some of these cases, no connection to the ticket provider would needto be established for fetching the control data but the secure elementor smart card could replace/deliver it. The secure element may also holdan algorithm to infer if the ticket status should be set to valid and itcould take any external information as its input (location, etc.) ornothing at all.

FIG. 5: Illustation of Ticket Appearance in an Active Ticket Stack

FIG. 5 shows six ticket appearances in an active ticket stack generallyindicated as 45 of the mobile terminal 22, that includes six (6) tickets50, 52, 54, 56, 58, 60, each having an animation section 50 a, an audiosection 50 b, a color section 50 c, as well as one or more othersections generally indicated as 50 d.

By way of example, a simple design is shown. With one animation and oneaudio, the control data indicates how frequent the animation is, howfast the audio is, what the background color of the animation image is,how light it is, etc. As shown, the issuer 24 provides the control datain the form of a token containing, e.g., the information “animation 3,audio 6, color 1, etc.” that determines the characteristic of ticketappearance 54. The scope of the invention is not intended to be limited,for example, to the number of active tickets stored in the stack 45, orthe type or kind of information stored in the stack 45.

FIG. 6: Active Ticketing Protocol

FIG. 6 shows, by way of example, an active ticketing protocol generallyindicated as 10, according to the present invention.

In summary, the active ticketing protocol 100 indicates that there canbe several active ticket in the mobile terminal 22 (depending on thewanted business model). Inside every active ticket there can be severalevent tickets (a ticket to a football match, movie, etc.) and each eventticket can have a series of life cycles.

In the active ticketing protocol 100, the mobile terminal provides arequest for an active ticket application to the ticket service provider.By way of example, the request is shown to have mobile informationdevice (MID) data and the ticket service provider is an applicationticket service provider. In response, the ticket service providergenerates an application active ticket with pre-valid event ticketsessions and downloads one or more ticket suites to the mobile terminal.After installation, the user of the mobile terminal starts and browsesthe active ticket application. To start a ticket life cycle, the user ofthe mobile terminal requests a valid ticket media with payment, time andlocation (with MID data) to the ticket service provider. In response,the ticket service provider verifies payment, upgrades the ticket statusand provides a valid appearance command (or valid set of media) to themobile terminal. At an appropriate time or place, the mobile terminalprovides a use valid ticket request to the ticket service provider. Inresponse, the ticket service provider verifies the appearance of theactive ticket, upgrades the ticket status, and provides a push cancelcommand (or invalid ticket media to the specified MID) to specified MIDwith new pre-ticket sessions, which ends the ticket life cycle. Eachticket life cycle has a similar active ticketing protocol.

FIG. 7: Valid Active Ticket Driven Methods (w/ Three AlternativeUpgrading Methods)

FIG. 7 shows a protocol for valid active ticket driven methods with thelast three upgrading methods being alternatives, including:

-   -   Payment driven,    -   Valid time driven (push new ticket appearance (i.e. upgraded        ticket package) to the ticket at a certain time, or send an        appearance change command to the ticket application.), and    -   Valid location driven (push new ticket appearance (i.e. upgraded        ticket package) to the ticket at a preferred location, or send        an appearance change command to the ticket application at        preferred location.)

Command Driven Methods

In operation, the mobile active terminal ticket application 22 b′verifies the command validity and changes the ticket appearanceaccordingly.

There are several ways to send command or media to the end user'sterminal, including via a broadcast method or push by request method.

Broadcast

In one embodiment, broadcast encryption technology can be used tobroadcast a ticket appearance driven command.

The theory of the broadcast encryption is as follows: The schemeaddresses the case when an authority broadcasts some valuable contentsand it is required that only legitimate clients should be able todecrypt the content. It also proposes efficient ways to trace down thetraitor who has constructed the new decryption.

The following steps can be applied for broadcasting the command to anumber of user terminals:

1. The ticket issuer generates a root key, which can derive a number ofseed keys.

2. Distribute the seed keys to the users before issuing the ticket.

3. Broadcast the command encryption by the root key and indicate whichseed keys can be used for decryption based on the data managed by theticket provider.

4. Only the user who is holding the valid seed keys (which are allowedto decrypt the command package) can decrypt the command package andupgrade the ticket appearance to the valid one.

The broadcast method can be used for time or location based ticketappearance driven

Push by Request

In an alternative embodiment, the mobile active ticket application 22 b′requests via payment or other measures to upgrade the appearance changeof the active ticket.

The characteristics of several tickets can be managed by the activeticket application. It controls the ticket status (e.g. pre-valid,valid, invalid, remove) through commands from the ticket provider. Oneimplementation method is as follows:

-   -   1) The active ticket application contains the ticket provider's        public key certificate,    -   2) Any command is signed by the provider and verified by the        active ticket application,    -   3) According to the content inside the valid command, the active        ticket changes the ticket status of the indicated ticket,    -   4) The latest ticket status could be managed at the secure        element of the terminal and protected by it. (For Java        implemented active ticket application, it could access the        status through the JSR 177 APIs).

Payment Consideration

It is preferred that payment works as a valid ticket appearance driven.It helps to realize equal-value data exchange. Mobile payment can beembedded into the ticket application. One possible implementation is amessage-based micro-payment that can be implemented inside the ticketapplication (the one possible implementation of active ticket is a Javaapplication). The ticket application can send SMS to the ticket providerwhich contains payment data in order to request next the valid ticketappearance. Other payment schemes may be implemented using voice call orHTTP protocols.

As the one example explained above shows: An active ticket can contain apayment initiator/payment method. This is probably new in ticketing.Also, payments and purchases can be made through existing or appearingsystems.

DRM Protection

In the present invention, ticket valid appearance is driven to the validdevice and checked by the device. Illegal copy of the active ticketapplication cannot get a valid appearance driven package (command and/ornew media). In this way, the invention can defend a digital rightscompromise.

Other Advantages of the Invention

Other advantages of the invention include:

-   -   Mobile terminal storage saving, and    -   Mobile teriminal power saving.

Due to the storage and processing limitation of the mobile terminal, itis impossible to package heavy media with the application. The inventionprovides a safe way to support multimedia ticketing with rounds of lifecycle, and at the same time, saves the terminal's memory.

FIG. 8 a: One Ticketing Protocol

FIG. 8 a illustrates a ticketing protocol in which a pre-valid ticket isinitially provided to the ticket user terminal. In this protocol, theticket user terminal provides a ticket request to a ticket issuerserver. In response, the ticket issuer server generates a prevalidticket and sends a message to the ticket user terminal containing aticket confirmation and the prevalid ticket. The ticket user terminalmay then provide to the ticket issuer server a purchase request withpurchase options. In response, the ticket issuer server generates a billand a valid ticket and sends to the ticket user terminal a messagecontaining the valid ticket or valid ticket token. Upon receiving themessage, the ticket user terminal may upgrade the prevalid ticket to avalid ticket. In order to use the active ticket, the user of the ticketuser terminal either shows or beams the valid ticket to a ticketinspector, who verifies the active ticket by identifying the ticketinformation via its characteristic (e.g. appearance) or a machine maycheck the ticket data. After the ticket is used, either the ticketissuer server or the ticket inspector may disable the active ticket byeither upgrading the valid ticket to an invalid ticket or destroying thevalid ticket.

The basic idea is to form an active ticket having several states withdifferent appearances carried by different applications. As shown, theDigital Rights Management (DRM) usage control is different at differentstates. For example, a pre-valid ticket application may be provided withforward and copy free, embedded with payment initiator. A valid ticketapplication may be provided with forward and copy disable will be sentto the user's terminal after payment to replace the pre-valid ticket ifnecessary. An invalid ticket application may be provided with forwardand copy free, will be sent to the user's terminal after ticketredemption and replace the valid ticket.

If security requirement is not high, a new ticket application can bereplaced by a control token push (with new rights) to instruct a newticket show.

The technique support may include using an OTA provision for upgrading aticket with a new status. and DRM protection needed for the valid ticketapplication (forward and copy are not allowed).

The advantages include compatibility with OMA DRM, and different statuswith different copy rights benefits ticket delivery (ad hoc delivery atthe pre-valid ticket stage), as well as greatly supporting mobilepayment by making it as the easiest way of ticket purchasing.

Some disadvantages include that the provision of the application causesmore rounds of communication, which can be improved by sending a controltoken message together with new rights. In addition, this approachcannot be supported by older mobile terminals.

FIG. 8 b: Active Ticketing Protocol with Cross Check

FIG. 8 b illustrates a ticketing protocol in which a pre-valid ticket isinitially provided to the ticket user terminal and cross-checking isperformed on payment status.

In this protocol, the ticket user terminal provides a ticket request toa ticket issuer server. In response, the ticket issuer server generatesa prevalid ticket and sends a message to the ticket user terminalcontaining a ticket confirmation and the prevalid ticket. The ticketuser terminal may then provide to the ticket issuer server a purchaserequest with purchase options. In response, the ticket issuer servercross-checks the payment status, generates a bill and correspondingcontrol token and sends to the ticket user terminal a message containingthe ticket control token. Upon receiving the message, the ticket userterminal will show a correct ticket appearance according to the ticketcontrol token. The remainder of the protocol is similar to thatdiscussed above.

The basic idea here is to have the active ticket running started atpre-valid status, and cross check the payment with the issuer to decideits latest status and appearance, including:

-   -   1. Have not paid—pay now or later,    -   2. Have paid—show valid ticket appearance, and    -   3. Have used—show invalid ticket appearance

The technique support for this approach includes a communicationtechnique to cross contact the ticket issuer securely (WMA, HTTPS,etc.). Moreover, in order to support ad hoc delivery, payment shouldattach to a unique number.

The advantages of this approach include: 1) It is unique from OMA DRM,but the ticket delivery can be supported by OMA DRM. 2) It greatlysupports mobile payment by making it the easiest way of ticket purchase.3) It freely supports super distribution of a ticket. 4) It supportsusing older terminals.

The disadvantages include the need to cross contact with the issuercauses more time, which may raise communication bottle.

FIG. 8 c: Location-Based Active Ticketing Protocol

FIG. 8 c illustrates a ticketing protocol based on a location-basedscheme.

In this protocol, the ticket user terminal provides a ticket request toa ticket issuer server. In response, the ticket issuer server generatesa ticket and sends a message to the ticket user terminal containing aticket confirmation and the ticket. The ticket user terminal may thenprovide to the ticket issuer server a purchase request with purchaseoptions. In response, the ticket issuer server generates a bill and aunique ticket id link to the user's terminal and sends a message to theticket user terminal with a payment confirmation. Upon receiving themessage, the active ticket in the ticket user terminal will change somecharacteristic, like appearance, according to the payment confirmation.At a suitable time and location, the ticket issuer server sends to theticket user terminal a ticket control token. Upon receiving the message,the ticket in the ticket user terminal will be upgraded to a validticket then back to the previous appearance after a limited time. Theremainder of the protocol is similar to that discussed above.

The basic idea here is to have a driven valid ticket appearance forverification at a suitable time and location by displaying a validticket appearance for a limited time, then replacing it by an invalidappearance.

The technique is a location and time based ticket active technique.

The advantages include the following: 1) it is unique from OMA DRM,although the ticket delivery can be supported by OMA DRM, 2) it greatlysupports mobile payment by making it as the easiest way of a ticketpurchase, 3) it freely supports super distribution of ticket and 4) itsupport older terminals.

Some disadvantages include the fact that advanced technology is neededfor location/time based ticket control.

FIG. 9 a: Use Case Ticket Purchase Protocol

FIG. 9 a shows an active ticketing application used to purchase a newticket. In this case, there can be tickets that are actually activetickets, implemented as applications or native Symbian applications(files for applications) using or not using Wallet or something else.These tickets can be listed as applications in the Tickets menu but theyare viewed and used via the application. As an overview, an applicationis used to purchase a new event ticket. The ticket is sent as a MeTticket and is therefore visible at the terminal Ticket menus. Aspre-conditions, the mobile terminal must support MeT tickets and theapplication to be used must be installed.

The procedure includes the following steps:

1. The user opens the tickets menu and starts a Java ticketingapplication like TicketServiceINC, for example.

2. The application shows an advertisement of a poster about a concertthat the user wants to attend. The user selects ‘Purchase’ and istransferred to a checkout form that asks for shipping address andpayment details.

3. The user views that information on the application and confirms thepurchase. Data is sent to the server. The user receives information thatpayment has been accepted and the key for the ticket that will bedelivered soon to the terminal has been received. This communication ispreferrably proprietary and may vary among different applications. Theapplication shows information that the ticket has been purchased.

4. The application receives a URL indicating where to download the fileand downloads it or invokes a Browser to do it.

5. The mobile terminal then tells the user that a ticket has beenreceived. The user looks at the ticket and sees it is the ticket he justpurchased so he selects to save the ticket. The ticket is saved to undera Tickets menu/folder.

6. The application can check that the ticket has been downloaded if itso chooses. The user can close the Browser and the application if he sochooses.

Post conditions include downloading the ticket to the mobile terminal.

Other noteworthy criteria include providing that the active ticketapplications could support the MeT tickets that the mobile terminalsupport understands (the Ticket Data part) as well as its ownproprietary tickets.

FIG. 9 b: Alternative Use Case Ticket Purchase Protocols

As an alternative to the protocol in FIG. 9 a, the active ticket mightbe just sent to the active ticket application and never be shown toterminal MeT ticket support. The scope of the invention is not intendedto preclude such applications from existing. They are not described inthis use case. In this scheme the ticket is delivered to the mobileterminal similarly to any MeT ticket.

In another embodiment, the active ticket may be received by theapplication and then sent to a centralized ticket manager or menu. Thismay be considered a more complex way and requires an active ticketapplication to support sending a ticket to the mobile terminal, whichdoes not bring any extra benefit to the active ticket application itselfand would then be unlikely to be implemented in it.

Alternatively, the MeT ticket may be used to support an encrypted part.In this security scheme, the keys for the ticket encrypted part can bedelivered to the application after the application has given its uniquekey or number (created at installation) and the payment. The server thenencrypts part of the ticket so that only this installed application canopen it; or alternative key solutions can be used. The user is nowholder of a payed ticket and it shows in the appearance of the ticket.The idea of the active ticket is that just downloading the applicationand a copied ticket does not make you a valid ticket holder.

Before the use of the ticket, a key or command is broadcast or pushed tothe terminal to indicate a valid status (out of the scope of thepurchase phase).

If the user accidentally deletes the ticket before saving, the user candownload it contacting the ticket service provider from the activeticket application. There can be checks done based on MSISDN orsomething else whether the user has purchased the ticket.

An electronic receipt may be send to the terminal or the active ticketmodule.

Ticket Browsing

The ticket browsing may work, as follows:

The active ticket could be an application, e.g. possibly a Javaapplication, the end user can activate it by running the mobile activeticket application, or it can be activated by the ticket provider tosend a smart message to the user.

If the active ticket is stored in the terminal MeT ticket support or theticket is just a link to the network (MeT virtual ticket) or anapplication, these tickets all can be listed in one Tickets menu in theterminal and viewed from there.

FIG. 10 a: Validation of Ticket Purchase

The scope of the invention is intended to include using BlueTooth,InfraRed, RFID, WLAN or other radio protocol for validationcommunication in addition to presentation based validation (visual,according to the ticket apprearance). Or it can use optical readingbased on the amount or frequency of the emitted light. Optionally, theactive ticket implementation can use smart card services via JSR 177.

For example, FIG. 10 a shows a scheme for ticket validation generallyindidated as 70. In FIG. 10 a, a mobile terminal 72 received an activeticket downloaded from ticket servers 74. The mobile terminal 72includes a MIDlet module 72 a, a JSR 177 module 72 b, a JVM module 72 c,a smart card 72 d and a BT/IrDa/RFID/WLAN 72 e, which provides theactive ticket to a validation terminal 76 for validation.

FIG. 10 b: Alternative of Validation of Ticket Purchase

FIG. 10 b shows an alternative validation scheme generally indicated as80, in which an MeT ticket 82 is downloaded via a browser 84 to a wallet86 having a ticketing application 86 a that provides the MeT ticket 82to a local connectivity API 86 b. When used, the MeT ticket 82 isvalidated by a validation terminal 88. As shown, the ticketingapplication 86 a may also provide the MeT ticket 82 or some control partof it to a secured memory 89.

Validation in General

The following describes different ways validation can be done accordingto different technologies. These use mostly available technologies tostress the various possibilities that active ticket offers.

Reader terminal may also be handheld or another mobile terminal or PTD.

Validation can happen with a human checking the ticket appearance orother characteristic, or validation can happen with a camera andsoftware that can check these wanted characteristics automatically.

Using an Event Ticket

In this example, the user may open the ticket application and view aconcert ticket. The user may select the functionality button ‘Useticket’ when at the gate. Then the user may enter the ticketing gate andplaces the phone against the ticketing reader. The ticketing reader maygive a confirmation sound and the user gets in. The user may see thatthe ticket application has a marking thereon for use at a current timeand views the latest information about the show the user has received aswell as an advertisement about one or more articles of merchandiseavailable at a given price and/or location.

Using Event Ticket That Changes with an Image Ticket

In this example, the user may walk toward any manned gate where papertickets can be used. The user may see notice signs saying that the usershould place the ticket ready before entering the gates. The user mayopen his ticket, which may consist of a big picture that contains theruser's face with a visible watermark partly over it and the basic ticketdata. The user shows that to the ticket inspector while walking through.The inspector may notice the correct colours in the active ticket oralternatively the right sound or watermark picture. Any presentationformat of the active ticket can be used.

Using Ticket with Light Sensor

In this example, the user may walk toward the gate where mobile ticketscan be used automatically. The user may notice the signs saying that theuser should open the mobile phone and show the ticket when entering tothe gate. The user may go to the ticketing reader and places the user'smobile terminal towards the sensor. If nothing happens, then theinspector may then ask the user to select an option saying “use ticket”from the ticket. The user may place the mobile terminal again to theticketing reader and press “use ticket” option when placing the mobileterminal near the sensor terminal on the wall. If the terminal showsacceptance, then the user can enter.

The user then sees that the ticket is now altered as it is used. Theuser may receive information text about the show and advertisement aboutone or more articles of merchandise available at a given price and/orlocation.

Purchasing New Tickets to a Group

The following describes the purchasing of new tickets to a group:

In one example known as a reservation for all, purchase separately, theuser may select the places the user wants to reserve to the user's groupof, e.g., five persons. The user then gives the contact information(mobile phone number) of the persons at the reservation. The ticketservice contacts (SMS) each person to inform them that reservation hasbeen made for them and when the ticket must be paid at the latest. Eachperson can then purchase the ticket the way and format the personwishes.

In an alternative example, the user may be ready to pay for all and topurchase the tickets immediately as the user has a sophisticated mobilephone with RFID tag (or midlet support etc.). The user may purchase fivetickets and keeps them on the mobile terminal all the time. When thegroup goes to the event together, the user shows all the ticket withthis one mobile device to get everyone in.

Transfer of Active Tickets

The following is a discussion of how the active tickets may betransferred:

In one case, the user has purchased a set of tickets for a group offriends. The user wants to get the money back and give each their ownindividual ticket so that they are not on the user responsibility.

In this case, the user may upload the ticket back to the ticketingservice and give phone numbers on who to allow to download them. Eachperson will be sent an SMS with the information and unique ticketinformation code.

Alternatively, the web server on one mobile and others can contact it todownload the ticket (MeT ticket, MIDlet). In this case, there is no needto upload the ticket back, as the provider can send a command to removethe ticket.

In a second case, the user has all the tickets on the user'sapplication. The user meets a friend. The friend must have the Activeticket application on the user's friend's mobile terminal as well. Theuser opens the application and selects to transfer a certain ticket andamount of tickets. The user confirms and sends them to anotherapplication via Infrared/RF contactless/Bluetooth. The user's friendopens the application as well and selects to receive, and soon theuser's friend gets a message on the display saying that ticket ortickets has been received. Both see the situation on their applications.It also indicates that this ticket has been transferred from MIDlet IDor username.

This kind of transfer can be implemented on tickets that rely on secureelement or that require validation command from the server side and cannotify a server that they have been moved.

There are also secure ways for transferring the active ticket, asfollows:

1) Printing the ticket at the automatic ticket printer/sales desk eitherbefore or at the event. Then ticket handling, transfers etc. is manual.

2) Transfer before the download at the mobile. At the purchase ispossible to define that tickets are to be downloaded to differentterminals.

New Technologies Supporting Active Ticket

New technologies presently available support the implementation of theactive ticketing method and apparatus described herein, including:

1) MIDP 2.0.

2) WMA (JSR120): Making a convenient SMS-based payment from the activeticket is possible (to purchase valid tickets; and sending of thecontrol token to change the state of the active ticket.

3) Payment API JSR 229: For payment and possibly delivery of the controltoken to the active ticket.

4) OMA DRM: When providing copy and forward protection, it can be usedas one copy protection solution for the active ticket; andnon-supporting terminals can use other copy protection solutions.

Any of these are not necessary requirements for the active ticket, butcan support some implementations.

Using MIDP 2.0 for Active Ticketing

MIDP 2.0 provides a signed MIDlet mechanism and end-to-end security andfeatures the following:

1) It is possible to run a device trusted mobile application in themobile terminals (in a permission domain)—authenticate applicationissuer.

2) It is possible for the mobile application to gain access to theprivileged functionality.

3) It is possible to make a mobile application communicate with outsideunder restriction (e.g. WMA Push Registration Entry).

MIDP 2.0 has a push architecture that makes control token driven ticketappearance detectable and thus forces the ticket operation accordingly,has an over-the-air (OTA) Provisioning that benefits ticket (a Javaapplication) upgrade, and has enhanced user interface that supportsadvanced ticket presentation.

DRM Solutions

DRM solutions are also viable, including the following:

1) OMA DRM terminal support (operate Java ticket according to theauthorized usage rights by e.g. ODRL).

2) Dynamic ticket appearance controlled by the ticket token pushed tothe unique ticket—copy protection & super-distribution.

3) Perceptible digital watermarking to protect visible ticketinformation—issuer's authorization.

4) Ticket owner's photo can also be put into the ticket for easyverification—ticket owner's authentication.

5) Advantages include:

-   -   a) Supported by existing infrastructure/standard and mobile        device.    -   b) Avoid complicated PKI-DRM if possible.    -   c) Possible to push into market within a short period.

Scope of the Invention

Accordingly, the invention comprises the features of construction,combination of elements, and arrangement of parts which will beexemplified in the construction hereinafter set forth.

It will thus be seen that the objects set forth above, and those madeapparent from the preceding description, are efficiently attained and,since certain changes may be made in the above construction withoutdeparting from the scope of the invention, it is intended that allmatter contained in the above description or shown in the accompanyingdrawing shall be interpreted as illustrative and not in a limitingsense.

1. A method for providing an active ticket in a mobile terminal for useby a mobile terminal user, characterized in that at least one activeticket has a ticket characteristic that dynamically changes based on oneor more states in a life cycle of the active ticket.
 2. A methodaccording to claim 1, wherein dynamic changes to the ticketcharacteristic include multimedia changes or other presentation data,including text, sound, animation, video, still pictures, or somecombination thereof.
 3. A method according to claim 1, wherein the oneor more states in the life cycle include a state of being eitherpurchased, validated, invalidated, template, pre-valid, prepared, orsome combination thereof for one or more different events.
 4. A methodaccording to claim 1, wherein the ticket characteristic dynamicallychanges based on a payment by the user of the mobile terminal.
 5. Amethod according to claim 1, wherein the ticket characteristicdynamically changes based on a predetermined time, status or combinationthereof.
 6. A method according to claim 1, wherein the ticketcharacteristic dynamically changes based on a predetermined or changinggeographic location.
 7. A method according to claim 1, wherein theticket characteristic dynamically changes based on a purchasetransaction between a user of the mobile terminal and a ticket serviceprovider.
 8. A method according to claim 1, wherein a ticket serviceprovider provides future ticket characteristic information to the mobileterminal that determines and/or activates the ticket characteristic. 9.A method according to claim 8, wherein the ticket characteristicinformation includes ticket characteristic control data, a ticketcharacteristic algorithm, a new set of ticket related media or acombination thereof.
 10. A method according to claim 9, wherein theticket characteristic control data includes new control data to changethe ticket characteristic algorithm or other presentation data,including new parameter values.
 11. A method according to claim 9,wherein the control data is received at a certain time and/or location,or just before the at least one active ticket is to be used.
 12. Amethod according to claim 9, wherein the control data is sent to onlylegally purchased tickets based on a respective identification codeassociated with a respective mobile terminal.
 13. A method according toclaim 9, wherein the at least one active ticket is validated usingvisual or audio validation based on the ticket characteristic.
 14. Amethod according to claim 13, wherein the visual or audio validation isperformed by either a human, or a machine, or some combination thereof.15. A method according to claim 8, wherein the ticket service providerprovides the ticket characteristic information to the mobile terminalvia the Internet or a mobile network.
 16. A method according to claim 8,wherein the ticket service provider provides the ticket characteristicinformation to the mobile terminal using a Java-based protocol, e.g.MIDP Over-the-Air approach.
 17. A method according to claim 8, whereinthe ticket service provider controls the ticket characteristic byproviding a control token, including either one based on anInternational Mobile Equipment Identity (IMEI) or a provision based onIMEI.
 18. A method according to claim 13, wherein the ticketcharacteristic is an audio ticket characteristic and the audiovalidation is based a relative frequency change.
 19. A method accordingto claim 13, wherein the ticket characteristic includes an audiowatermark embedded therein using a secret key.
 20. A method according toclaim 19, wherein the audio validation is performed by a machine thatuses the secret key to detect and validate the at least one activeticket by listening to the sound thereof.
 21. A method according toclaim 19, wherein the at least one active ticket is implemented using aprotocol based on Mobile electronic Transactions (MeT), including theMeT ticket format.
 22. A method according to claim 21, wherein the MeTticket format contains only a template for a pre-valid active ticket.23. A method according to claim 21, wherein the mobile transaction (MeT)ticket format contains valid ticket information for a valid activeticket.
 24. A method according to claim 23, wherein the valid ticketinformation is removed from the MeT ticket for a used active ticket. 25.A method according to claim 1, wherein the method is implemented usingan active ticket system architecture having a mobile terminal and aticket service provider.
 26. A method according to claim 25, wherein theticket service provider includes a ticket generator responsible forgenerating the at least one active ticket for the mobile terminal.
 27. Amethod according to claim 25, wherein the ticket service providerincludes a ticket issuer for delivery and updating of the at least oneactive ticket, or upgrading an active ticket application at the mobileterminal.
 28. A method according to claim 25, wherein the ticket serviceprovider includes a memory device or database for ticket data and userinformation and logs.
 29. A method according to claim 25, wherein themobile terminal includes a mobile active ticket application that is theactive ticket installed and run on the mobile terminal.
 30. A methodaccording to claim 25, wherein the mobile terminal includes a tickettransaction module, which could support various payment methods,including a credit or debit card, or SMS based micropayment, forterminal user's preference, for supporting ticket purchases.
 31. Amethod according to claim 1, wherein the at least one active ticketincludes several active tickets.
 32. A method according to claim 31,wherein each of the several active tickets includes several differentevents.
 33. A method according to claim 31, wherein each active ticketincludes a respective series of life cycles.
 34. A method according toclaim 31, wherein the ticket service provider sends commands or media tothe mobile terminal using a broadcast encryption technique.
 35. A methodaccording to claim 34, wherein the broadcast encryption techniqueincludes the following steps: generating with a ticket issuer a rootkey, which can derive a number of seed keys; distributing the seed keysto users before issuing the active ticket; broadcasting a commandencryption by the root key to indicate which of the seed keys can beused for decryption based on data managed by the ticket serviceprovider; and allowing a user who is holding a valid seed key, which areallowed to decrypt the command package, to decrypt a command package andupgrade the ticket characteristic to a valid one.
 36. A method accordingto claim 31, wherein the ticket service provider sends commands or mediato the mobile terminal using a push by request technique, includingrequesting payment or other measures from the mobile terminal user toupgrade the ticket characteristic.
 37. A method according to claim 36,wherein the push by request technique includes the following steps:providing in an active ticket application a ticket provider's public keycertificate; signing any command by the ticket service provider andverifying the same by the active ticket application; and changing theticket status of an indicated active ticket based on the content insidea valid command.
 38. A method according to claim 31, wherein the mobileterminal sends the ticket service provider a short message servicesignal containing payment data in order to make the payment.
 39. Amethod according to claim 8, wherein the ticket characteristicinformation includes a URL address where to download a ticket filecontaining information related to the ticket characteristic.
 40. Amethod according to claim 39, wherein the mobile terminal saves theticket file.
 41. A method according to claim 39, wherein the mobileterminal saves information related to how/where to start an activeticket application.
 42. A mobile terminal for providing an active ticketfor use by a mobile terminal user, characterized in that the mobileterminal includes a mobile active ticket application module thatprovides at least one active ticket having a ticket characteristic thatdynamically changes based on one or more states in a life cycle of theactive ticket.
 43. A mobile terminal according to claim 42, whereindynamic changes to the ticket characteristic include multimedia changesor other presentation data, including text, sound, animation, video,still pictures, or some combination thereof.
 44. A mobile terminalaccording to claim 42, wherein the one or more states in the life cycleinclude a state of being either purchased, validated, invalidated,template, pre-valid, prepared, or some combination thereof for one ormore different events.
 45. A mobile terminal according to claim 42, theticket characteristic dynamically changes based on a payment by the userof the mobile terminal.
 46. A mobile terminal according to claim 42,wherein the ticket characteristic dynamically changes based on apredetermined time, status or combination thereof.
 47. A mobile terminalaccording to claim 42, wherein the ticket characteristic dynamicallychanges based on a predetermined or changing geographic location.
 48. Amobile terminal according to claim 42, wherein the ticket characteristicdynamically changes based on a purchase transaction between a user ofthe mobile terminal and a ticket service provider.
 49. A ticket serviceprovider for communicating with a mobile terminal, characterized in thatthe ticket service provider includes a ticket issuer module thatprovides to a mobile terminal either at least one active ticket orcontrol information for activating or deactivating at least one activeticket for use by a mobile terminal user, the at least one active tickethaving a ticket characteristic that dynamically changes based on one ormore states in a life cycle of the active ticket.
 50. A ticket serviceprovider according to claim 49, wherein dynamic changes to the ticketcharacteristic include either multimedia changes or other presentationdata, including text, sound, animation, video, still pictures; or amovement of the mobile terminal, an emission of light therefrom, achange of shape; or some combination thereof.
 51. A ticket serviceprovider according to claim 49, wherein the one or more states in thelife cycle include a state of being either purchased, validated,invalidated, template, pre-valid, prepared, or some combination thereoffor one or more different events.
 52. A ticket service provideraccording to claim 49, wherein the ticket characteristic dynamicallychanges based on a payment by the user of the mobile terminal.
 53. Aticket service provider according to claim 49, wherein the ticketcharacteristic dynamically changes based on a predetermined time, statusor combination thereof.
 54. A ticket service provider according to claim47, wherein the ticket characteristic dynamically changes based on apredetermined or changing geographic location.
 55. A ticket serviceprovider according to claim 47, wherein the ticket characteristicdynamically changes based on a purchase transaction between a user ofthe mobile terminal and a ticket service provider.
 56. A wirelessnetwork having a ticket service provider and a mobile terminal,characterized in that the mobile terminal receives from the ticketservice provider either at least one active ticket or controlinformation for activating or deactivating at least one active ticketfor use by a mobile terminal user, the at least one active ticket havinga ticket characteristic that dynamically changes based on one or morestates in a life cycle of the active ticket.
 57. A wireless networkaccording to claim 56, wherein dynamic changes to the ticketcharacteristic include multimedia changes or other presentation data,including text, sound, animation, video, still pictures, or somecombination thereof.
 58. A wireless network according to claim 56,wherein the one or more states in the life cycle include a state ofbeing either purchased, validated, invalidated, template, pre-valid,prepared, or some combination thereof for one or more different events.59. A wireless network according to claim 56, wherein the ticketcharacteristic dynamically changes based on a payment by the user of themobile terminal.
 60. A wireless network according to claim 56, whereinthe ticket characteristic dynamically changes based on a predeterminedtime, status or combination thereof.
 61. A wireless network according toclaim 56, wherein the ticket characteristic dynamically changes based ona predetermined or changing geographic location.
 62. A wireless networkaccording to claim 56, wherein the ticket characteristic dynamicallychanges based on a purchase transaction between a user of the mobileterminal and a ticket service provider.
 63. A method according to claim1, wherein the ticket characteristic dynamically changes only after someuser interaction based on an embedded algorithm in the active ticket andpossible control data received from a ticket issuer.
 64. A mobileterminal according to claim 42, wherein the ticket characteristicdynamically changes only after some user interaction based on anembedded algorithm in the active ticket and possible control datareceived from a ticket issuer.
 65. A ticket service provider accordingto claim 47, wherein the ticket characteristic dynamically changes onlyafter some user interaction based on an embedded algorithm in the activeticket and possible control data received from a ticket issuer.
 66. Awirless network according to claim 56, wherein the ticket characteristicdynamically changes only after some user interaction based on anembedded algorithm in the active ticket and possible control datareceived from a ticket issuer.
 67. A method according to claim 25,wherein the mobile terminal includes a centralized ticket manager forviewing and/or managing the tickets that a user has.
 68. A methodaccording to claim 1, wherein the ticket characteristic dynamicallychanges based on an embedded algorithm driven by a control token sent bythe ticket service provider.
 69. A mobile terminal according to claim42, wherein the ticket characteristic dynamically changes based on anembedded algorithm driven by a control token sent by the ticket serviceprovider.
 70. A ticket service provider according to claim 47, whereinthe ticket characteristic dynamically changes based on an embeddedalgorithm driven by a control token sent by the ticket service provider.71. A mobile network according to claim 56, wherein the ticketcharacteristic dynamically changes based on an embedded algorithm drivenby a control token sent by the ticket service provider.
 72. A methodaccording to claim 25, wherein the ticket service provider includes aticket inspector which may be a digital machine or human being forticket verification on its validity and correctness.
 73. A methodaccording to claim 1, wherein a number of ticket services support aremanaged at the same time or in series.
 74. A method according to claim73, wherein one ticket service depends on a previous ticket service.